A known problem in computer science involves effective programmability around concurrency. Existing programming paradigms involve such things as threads, mutexes, semaphores, critical sections, and other primitives. Though these have been around for decades, they are hard to use properly without inducing hard-to-find timing bugs, or inadvertently serializing access through code sections via improper locking hierarchies.
Though this has been an issue in the past, developers typically did not worry about it because they could count on their purely sequential code automatically running faster due to ever increasing CPU clock rates. This is changing, however, now that clock rates have hit the thermal barrier and CPU vendors are moving toward multi-core designs. This means that for a software developer to make their code run faster, they will need to split the work into multiple concurrent sections that can run across 2, 4, 32, 64, or even hundreds of local processors in a single machine. This is difficult to do with threads.
Additionally, there are latencies in distributed operating systems. For example, if a user issues a read request from their local disk using traditional local architectures, they are assured to get data back within a few milliseconds. But if the user does the same thing over a network to a remote machine, it may take seconds or minutes or forever to return the data. A new language called C-Omega has been developed and provides an alternative to threading for dealing with local concurrent programming. C-Omega, however, requires an entirely new language, infrastructure and toolchain (debuggers, etc.). Also C-omega takes a declarative approach, where any programming primitives are fixed at compile time and cannot be modified or adjusted based on runtime information. It would be desirable, therefore, if a mechanism were available to address the problem of concurrency and coordination in a concurrent and potentially distributed operating system, without the need for a new language.